JavaScript Iterator Helpers und parallele Ausführung: Ein tiefer Einblick in die konkurrente Stream-Verarbeitung

In der sich ständig weiterentwickelnden Landschaft der Webentwicklung ist Leistung nicht nur ein Feature, sondern eine grundlegende Anforderung. Da Anwendungen immer größere Datenmengen und komplexe Operationen verarbeiten, kann die traditionelle, sequenzielle Natur von JavaScript zu einem erheblichen Engpass werden. Vom Abrufen Tausender Datensätze von einer API bis zur Verarbeitung großer Dateien ist die Fähigkeit, Aufgaben konkurrent auszuführen, von größter Bedeutung.

Hier kommt der Iterator Helpers-Vorschlag ins Spiel, ein Stage-3-Vorschlag von TC39, der die Art und Weise, wie Entwickler mit iterierbaren Daten in JavaScript arbeiten, revolutionieren wird. Während sein Hauptziel darin besteht, eine reichhaltige, verkettbare API für Iteratoren bereitzustellen (ähnlich dem, was `Array.prototype` für Arrays bietet), eröffnet seine Synergie mit asynchronen Operationen eine neue Dimension: elegante, effiziente und native konkurrente Stream-Verarbeitung.

Dieser Artikel führt Sie durch das Paradigma der parallelen Ausführung mit asynchronen Iterator Helpers. Wir werden das 'Warum', das 'Wie' und das 'Was kommt als Nächstes' untersuchen und Ihnen das Wissen vermitteln, um schnellere und widerstandsfähigere Datenverarbeitungspipelines in modernem JavaScript zu erstellen.

Der Engpass: Die sequenzielle Natur der Iteration

Bevor wir uns der Lösung widmen, wollen wir das Problem klar definieren. Stellen Sie sich ein gängiges Szenario vor: Sie haben eine Liste von Benutzer-IDs, und für jede ID müssen Sie detaillierte Benutzerdaten von einer API abrufen.

Ein traditioneller Ansatz mit einer `for...of`-Schleife und `async/await` sieht sauber und lesbar aus, hat aber einen versteckten Leistungsnachteil.

            
async function fetchUserDetailsSequentially(userIds) {
  const userDetails = [];
  console.time("Sequential Fetch");

  for (const id of userIds) {
    // Jedes 'await' pausiert die gesamte Schleife, bis das Promise aufgelöst wird.
    const response = await fetch(`https://api.example.com/users/${id}`);
    const user = await response.json();
    userDetails.push(user);
    console.log(`Fetched user ${id}`);
  }

  console.timeEnd("Sequential Fetch");
  return userDetails;
}

const ids = [1, 2, 3, 4, 5];
// Wenn jeder API-Aufruf 1 Sekunde dauert, benötigt diese gesamte Funktion ca. 5 Sekunden.
fetchUserDetailsSequentially(ids);

            

              
                Copy
              
            
          

In diesem Code blockiert jedes `await` innerhalb der Schleife die weitere Ausführung, bis die jeweilige Netzwerkanfrage abgeschlossen ist. Wenn Sie 100 IDs haben und jede Anfrage 500 ms dauert, beträgt die Gesamtzeit unglaubliche 50 Sekunden! Dies ist höchst ineffizient, da die Operationen nicht voneinander abhängig sind; das Abrufen von Benutzer 2 erfordert nicht, dass die Daten von Benutzer 1 bereits vorhanden sind.

Die klassische Lösung: `Promise.all`

Die etablierte Lösung für dieses Problem ist `Promise.all`. Es ermöglicht uns, alle asynchronen Operationen auf einmal zu starten und auf den Abschluss aller zu warten.

            
async function fetchUserDetailsWithPromiseAll(userIds) {
  console.time("Promise.all Fetch");

  const promises = userIds.map(id => 
    fetch(`https://api.example.com/users/${id}`).then(res => res.json())
  );

  // Alle Anfragen werden konkurrent gestartet.
  const userDetails = await Promise.all(promises);

  console.timeEnd("Promise.all Fetch");
  return userDetails;
}

// Wenn jeder API-Aufruf 1 Sekunde dauert, dauert dies nun nur noch ca. 1 Sekunde (die Zeit der längsten Anfrage).
fetchUserDetailsWithPromiseAll(ids);

            

              
                Copy
              
            
          

Promise.all ist eine massive Verbesserung. Es hat jedoch seine eigenen Einschränkungen:

• Speicherverbrauch: Es erfordert, dass im Voraus ein Array aller Promises erstellt wird und alle Ergebnisse im Speicher gehalten werden, bevor sie zurückgegeben werden. Dies ist bei sehr großen oder unendlichen Datenströmen problematisch.
• Keine Backpressure-Kontrolle: Es startet alle Anfragen gleichzeitig. Bei 10.000 IDs könnten Sie Ihr eigenes System, die Ratenbegrenzungen des Servers oder die Netzwerkverbindung überlasten. Es gibt keine eingebaute Möglichkeit, die Konkurrenz auf beispielsweise 10 Anfragen gleichzeitig zu begrenzen.
• Alles-oder-Nichts-Fehlerbehandlung: Wenn ein einziges Promise im Array ablehnt (reject), lehnt `Promise.all` sofort ab und verwirft die Ergebnisse aller anderen erfolgreichen Promises.

Genau hier zeigt sich die Stärke von asynchronen Iteratoren und den vorgeschlagenen Helpers. Sie ermöglichen eine streambasierte Verarbeitung mit feingranularer Kontrolle über die Konkurrenz.

Asynchrone Iteratoren verstehen

Bevor wir rennen können, müssen wir gehen. Lassen Sie uns kurz asynchrone Iteratoren rekapitulieren. Während die `.next()`-Methode eines regulären Iterators ein Objekt wie `{ value: 'some_value', done: false }` zurückgibt, gibt die `.next()`-Methode eines asynchronen Iterators ein Promise zurück, das zu diesem Objekt auflöst.

Dies ermöglicht uns, über Daten zu iterieren, die im Laufe der Zeit eintreffen, wie z.B. Chunks aus einem Dateistream, paginierte API-Ergebnisse oder Ereignisse von einem WebSocket.

Wir verwenden die `for await...of`-Schleife, um asynchrone Iteratoren zu konsumieren:

            
// Eine Generatorfunktion, die jede Sekunde einen Wert liefert (yield).
async function* createSlowStream() {
  for (let i = 1; i <= 5; i++) {
    await new Promise(resolve => setTimeout(resolve, 1000));
    yield i;
  }
}

async function consumeStream() {
  const stream = createSlowStream();
  // Die Schleife pausiert bei jedem 'await', bis der nächste Wert geliefert wird.
  for await (const value of stream) {
    console.log(`Received: ${value}`); // Gibt 1, 2, 3, 4, 5 aus, einen pro Sekunde
  }
}

consumeStream();

            

              
                Copy
              
            
          

Der Game Changer: Der Iterator-Helpers-Vorschlag

Der TC39 Iterator-Helpers-Vorschlag fügt bekannte Methoden wie `.map()`, `.filter()` und `.take()` direkt zu allen Iteratoren (sowohl synchron als auch asynchron) über `Iterator.prototype` und `AsyncIterator.prototype` hinzu. Dies ermöglicht uns, leistungsstarke, deklarative Datenverarbeitungspipelines zu erstellen, ohne den Iterator zuerst in ein Array umwandeln zu müssen.

Betrachten wir einen asynchronen Strom von Sensormesswerten. Mit asynchronen Iterator Helpers können wir ihn wie folgt verarbeiten:

            
async function processSensorData() {
  const sensorStream = getAsyncSensorReadings(); // Gibt einen asynchronen Iterator zurück

  // Hypothetische zukünftige Syntax mit nativen asynchronen Iterator Helpers
  const processedStream = sensorStream
    .filter(reading => reading.temperature > 30) // Nach hohen Temperaturen filtern
    .map(reading => ({ ...reading, temperature: toFahrenheit(reading.temperature) })) // In Fahrenheit umrechnen
    .take(10); // Nur die ersten 10 kritischen Messwerte nehmen

  for await (const criticalReading of processedStream) {
    await sendAlert(criticalReading);
  }
}

            

              
                Copy
              
            
          

Das ist elegant, speichereffizient (es verarbeitet ein Element nach dem anderen) und sehr gut lesbar. Allerdings ist der Standard-`.map()`-Helfer, selbst für asynchrone Iteratoren, immer noch sequenziell. Jede Mapping-Operation muss abgeschlossen sein, bevor die nächste beginnt.

Das fehlende Puzzleteil: Konkurrentes Mapping

Die wahre Stärke für die Leistungsoptimierung liegt in der Idee einer konkurrenten Map. Was wäre, wenn die `.map()`-Operation mit der Verarbeitung des nächsten Elements beginnen könnte, während auf das vorherige noch gewartet wird? Das ist der Kern der parallelen Ausführung mit Iterator Helpers.

Obwohl ein `mapConcurrent`-Helfer nicht offiziell Teil des aktuellen Vorschlags ist, ermöglichen uns die von asynchronen Iteratoren bereitgestellten Bausteine, dieses Muster selbst zu implementieren. Das Verständnis, wie man es erstellt, bietet tiefe Einblicke in die moderne JavaScript-Konkurrenz.

Einen konkurrenten `map`-Helfer erstellen

Entwerfen wir unseren eigenen `asyncMapConcurrent`-Helfer. Es wird eine asynchrone Generatorfunktion sein, die einen asynchronen Iterator, eine Mapper-Funktion und ein Konkurrenzlimit entgegennimmt.

Unsere Ziele sind:

1. Mehrere Elemente aus dem Quell-Iterator parallel verarbeiten.
2. Die Anzahl der konkurrenten Operationen auf ein bestimmtes Niveau begrenzen (z.B. 10 gleichzeitig).
3. Ergebnisse in der ursprünglichen Reihenfolge liefern, in der sie im Quell-Stream erschienen sind.
4. Backpressure natürlich handhaben: Elemente nicht schneller aus der Quelle ziehen, als sie verarbeitet und konsumiert werden können.

Implementierungsstrategie

Wir verwalten einen Pool aktiver Aufgaben. Wenn eine Aufgabe abgeschlossen ist, starten wir eine neue und stellen sicher, dass die Anzahl der aktiven Aufgaben unser Konkurrenzlimit nie überschreitet. Wir speichern die ausstehenden Promises in einem Array und verwenden `Promise.race()`, um zu erfahren, wann die nächste Aufgabe beendet ist, was uns ermöglicht, ihr Ergebnis zu liefern (yield) und sie zu ersetzen.

            
/**
 * Verarbeitet Elemente eines asynchronen Iterators parallel mit einem Konkurrenzlimit.
 * @param {AsyncIterable} source Der asynchrone Quell-Iterator.
 * @param {(item: T) => Promise} mapper Die asynchrone Funktion, die auf jedes Element angewendet wird.
 * @param {number} concurrency Die maximale Anzahl paralleler Operationen.
 * @returns {AsyncGenerator}
 */
async function* asyncMapConcurrent(source, mapper, concurrency) {
  const executing = []; // Pool der aktuell ausgeführten Promises
  const iterator = source[Symbol.asyncIterator]();

  async function processNext() {
    const { value, done } = await iterator.next();
    if (done) {
      return; // Keine weiteren Elemente zu verarbeiten
    }
    
    // Die Mapping-Operation starten und das Promise zum Pool hinzufügen
    const promise = Promise.resolve(mapper(value)).then(mappedValue => ({ 
        result: mappedValue,
        sourceValue: value
    }));

    executing.push(promise);
  }

  // Den Pool mit initialen Aufgaben bis zum Konkurrenzlimit füllen
  for (let i = 0; i < concurrency; i++) {
    processNext();
  }

  while (executing.length > 0) {
    // Warten, bis eines der ausstehenden Promises aufgelöst wird
    const finishedPromise = await Promise.race(executing);

    // Den Index finden und das abgeschlossene Promise aus dem Pool entfernen
    const index = executing.indexOf(finishedPromise);
    executing.splice(index, 1);

    const { result } = await finishedPromise;
    yield result;

    // Da ein Platz frei geworden ist, eine neue Aufgabe starten, falls es weitere Elemente gibt
    processNext();
  }
}

            

              
                Copy
              
            
          

            
// Helfer zur Simulation eines API-Aufrufs mit zufälliger Verzögerung
function fetchUser(id) {
  const delay = Math.random() * 1000 + 500; // 500ms - 1500ms Verzögerung
  return new Promise(resolve => {
    setTimeout(() => {
      console.log(`Resolved fetch for user ${id}`);
      resolve({ id, name: `User ${id}`, fetchedAt: Date.now() });
    }, delay);
  });
}

// Ein asynchroner Generator, um einen Stream von IDs zu erstellen
async function* createIdStream() {
  for (let i = 1; i <= 20; i++) {
    yield i;
  }
}

async function main() {
  const idStream = createIdStream();
  const concurrency = 5; // 5 Anfragen gleichzeitig verarbeiten

  console.time("Concurrent Stream Processing");

  const userStream = asyncMapConcurrent(idStream, fetchUser, concurrency);

  // Den resultierenden Stream konsumieren
  for await (const user of userStream) {
    console.log(`Processed and received:`, user);
  }

  console.timeEnd("Concurrent Stream Processing");
}

main();

            

              
                Copy